AWS Database Migration Serviceを試してみた
西澤です。つい先日DMS(Data Migration Service)が正式リリースとなりました。ということで、早速必要となる情報の整理をした上で、試してみることにしました。
DMSを構成する要素
DMSは以下の要素で構成されます。移行元および移行先データベースを除くと、レプリケーションインスタンス、エンドポイント、タスクを組み合わせて構成することになります。
- データベース
- 移行元データベース
- 移行先データベース
- レプリケーションインスタンス
- エンドポイント
- ソースエンドポイント
- ターゲットエンドポイント
- タスク
- migrate existing data(初期転送のみ)
- migrate existing data and replicate ongoing changes(初期転送後、差分転送開始)
- replicate data changes only(差分転送のみ)
データベースはいずれか一方がAWS内にあれば、DB on EC2でもRDSでもサポートされています(オンプレtoオンプレはNG)。今回はRDSからRDSへの移行を試してみました。オンプレ環境との接続を意識した構成とする為、VPC Peeringを利用して試してみようと思います。
DMSの利用料金
現時点での利用料金は以下の通りです。
レプリケーションインスタンス利用料金
レプリケーションインスタンスには、下記のインスタンスタイプを利用できます。EC2 Linuxよりも少し割高な料金になっています。
| インスタンスタイプ | レプリケーションインスタンス | EC2 Linux |
|---|---|---|
| t2.micro | $0.028 | $0.02 |
| t2.small | $0.056 | $0.04 |
| t2.medium | $0.112 | $0.08 |
| t2.large | $0.196 | $0.16 |
| c4.large | $0.224 | $0.133 |
| c4.xlarge | $0.391 | $0.265 |
| c4.2xlarge | $0.783 | $0.531 |
| c4.4xlarge | $1.564 | $1.061 |
※ 2016年3月時点、東京リージョン利用の場合
レプリケーションインスタンスストレージ
一時領域として利用されるレプリケーションストレージのローカルストレージとして、汎用SSD(gp2)が利用されます。こちらもEC2よりも少し割高となっているだけです。
- レプリケーションインスタンス用ストレージ
- $0.138/GB-month
※ EC2 EBSのgp2は$0.10/GB-month ※ 2016年3月時点、東京リージョン利用の場合
データ転送料金、その他
データ転送料金として、通常のAWSデータ通信費用がかかります。移行先DBがAWS内にあれば、ほとんどはInbound通信になるので問題とはならないはずです。その他、レプリケーションの記録をCloudWatch Logsに保存することができますので、こちらにも若干の費用がかかります。
やってみる
それでは、早速やってみましょう。今回は理解を深める為、"Get strated"は使わずに、1つずつ構成してみようと思います。
Replication Subnet Group作成
まずは、レプリケーションインスタンスを配置するReplication Subnet Groupを作成します。RDS用に作成するSubnet Groupと作り方はほとんど同じです。2つ以上のAZにまたがるようにSubnet Groupを構成しましょう。
Replication Instance作成
レプリケーションインスタンスを作成しましょう。
インスタンスタイプは一番小さいt2.smallにしておきました。今回の構成では、Publicly Accessibleとする必要は無かったのですが、オンプレとの通信する際に閉域網が構成できないケースを想定してチェックを入れてみました。詳細は後述します。
ストレージサイズは移行データ量に合わせて変更する必要がありそうですが、インスタンスタイプと合わせて後から変更が可能です。また、レプリケーションインスタンスのローカルストレージにはデフォルトでKMSによる暗号化が行われます。Defaultを選んでおけば自動的にキーを作成してくれるようです。
しばらく待てばレプリケーションインスタンスが起動します。
Replication InstanceのENI設定
レプリケーションインスタンスの作成画面では、指定箇所はありませんが、EC2画面からENIを確認することができました。こちらを操作すれば、EIP利用によるグローバルIPの固定化やSecurity Group設定を行うこともできました。レプリケーションインスタンスに外部から接続する要件はありませんので、Inboundは全て拒否にしてしまっても問題はありません。外部との通信で、Firewallを超える必要があるケースでは、EIPが使えるのは良いですね。
2016年7月のアップデート以降、Replication InstanceのENI設定から、Elastic IPを割り当てることはできなくなったようです。通信するPublilc IP固定化を行いたい場合には、NATインスタンス、NATゲートウェイを利用する必要がありますので、ご注意ください。
Endpoint作成
Source、TargetとなるEndpoint(データベースへの接続定義)を作成します。
移行元のEndpointを作成したらRun Testを実行しましょう。この定義は、後から変更も可能で、何度でも接続テストをすることができます。
移行元データベース用の設定については、下記ドキュメントに詳しく記載されています。接続試験で確認してくれるのは疎通確認程度のようですので、前提条件をクリアできているか、必ず確認してください。
続けて、移行先のエンドポインを作成します。こちらもRun testをしておきましょう。
移行先データベース用の設定については、下記ドキュメントに詳しく記載されています。接続試験で確認してくれるのは疎通確認程度のようですので、前提条件をクリアできているか、必ず確認してください。
今回は空欄のままとしましたが、Extra connection attributesに指定できるパラメータは下記ドキュメントに詳しく記載がありました。各DBエンジン別のSource、Target用に外部から移行用の設定が可能なようです。
こちらは作成して間もなく利用できるようになりました。
Task作成
これで、レプリケーション用のインスタンスと接続先情報が整いましたので、データ移行をやってみましょう。
今回は、Migrating existing data(初期転送のみ)を試してみます。
ロギング設定を有効にすると、レプリケーションのログがCloudWatch Logsから参照可能となりますので、必ずチェックを入れて確認できるようにしておきましょう。その他の設定はデフォルトとしました。
今回はROOTスキーマを移行してみます。
Runningになりました！上手く行くかどうか見ていると。。。
なんと失敗。。。Tables erroredが1となっていました。
CloudWatch Logsからログを確認
CloudWatch Logsからログを確認してみましょう。今回はパッケージ製品のDBを移行元としたので、一応テーブル名はマスクしていますが、移行に失敗したテーブルとその原因を特定することができました。行サイズの上限を超えるテーブル定義となっていたようです。
特定テーブルを除外して再実行
問題となったテーブルの移行は、別で対応するものとして、今回はこのテーブルを除いてタスクを再実行してみました。タスク作成のテーブルマッピング設定を利用して、特定テーブルを移行対象から除外(Exclude)指定しました。
ようやくエラーとなったテーブル以外のデータ移行は無事成功しました!
まとめ
今回はDMSを利用したイニシャルデータ転送までを試してみました。実際のデータベース移行では、色々な問題が発生する可能性がありますが、このDMSがデータ移行を手助けしてくれる強力なツールになることは間違いなさそうです。またの機会に、Replicate ongoing changes(Change Data Capture：CDC)による差分転送や、DMSによる移行を補助する位置付けとなっているAWS Schema Conversion Toolも試してみたいと思います。
誰かのお役に立てば嬉しいです。
